Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-telnet-transfer-option-00.txt < prev next >

Wrap

Text File | 1993-07-08 | 16.2 KB | 405 lines

Network Working Group S. Denton Internet-Draft Coal Services Corp. June 1993 TELNET Transfer Control Option Status of this Memo This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Motivation There has come into being on the Internet a number of loosely coupled hypertext multi-user databases (aka MUDs). These may be characterized by the existence of a network-unique cursor object (aka player) which may be passed from host to host when the user is following what appears to be an otherwise normal database link. Although the security requirements of these systems are no greater than those of anonymous FTP, each system keeps track of the user's location within the database so that each new session starts where the previous session ended. For this reason, an arbitrary user identifier is generated the first time a connection is made, and a simple password protocol is used to avoid accidentally using another user's cursor. Users normally connect to these databases using a client program that emulates a simple Network Virtual Terminal. Currently, the hand-off of a cursor from one host to another is accomplished by a procedure the details of which vary from system to system. For the purposes of this dissusion, the procedure used by the UnterMUD system will be described. The current host establishes a connection to the proposed host using a previously agreed upon port number; the current host transfers the contents of the cursor object to the proposed host via this connection; when and if the transfer has been successfully completed, the current host marks the cursor object as "not-in-use" and sends a message to the user requesting a transfer to the proposed host. The message has the fixed format "#### Please reconnect to MyMUD@123.45.67.89 (MUDHOST.YOYODYNE.COM) port 12345 ####". The user is then expected to manually break the Telnet connection and establish a new connection to the specified port. Many of the more specialized client programs recognize this S. Denton Expires December 1993 [Page 1] Internet-Draft TELNET Transfer Control Option June 1993 message and attempt to perform the transfer transparently. The author conjectures that a formalized version of this protocol would not only be convenient for the users of these databases, but could be useful in its own right. Several services utilize the Telnet protcol for communications to a client. Using this protcol, a Telnet connection to a service could be dynamically switched to another host for purposes of load sharing or to facilitate a simpler data path for information retrieval. E.g., after connecting to an FTP server, a client may issue a CWD to a directory that is remotely mounted via NFS from another host that also provides FTP services. In this case, the client could be advised that an alternative connection is preferred. Also, the method currently in use is subject to "spoof"-ing. A message that resembles the transfer request may accidentally be placed into a MUD (in help text, for instance) where the client NVT will mistake the message for a genuine transfer request. Utilization of a Telnet option subnegotiation would make a transfer request unambiguous. 1. Command names and codes XFER_CTRL to be assigned Commands IS 0 SEND 1 INFO 2 NAME 3 Roles CLIENT 0 SERVER 1 2. Command meanings IAC WILL XFER_CTRL The sender of this command REQUESTS permission to, or confirms that it will, suggest transfer to/from another server. IAC WONT XFER_CTRL The sender of this command REFUSES to suggest transfer to/from another server. IAC DO XFER_CTRL The sender of this command REQUESTS that the receiver, or grants the receiver permission to, suggest transfers between servers. S. Denton Expires December 1993 [Page 2] Internet-Draft TELNET Transfer Control Option June 1993 IAC DONT XFER_CTRL The sender of this command DEMANDS that the receiver not suggest transfers between servers. IAC SB XFER_CTRL NAME <alternate port> IAC SE The sender specifies a remote host to which the connection must be transferred immediately. The sender has already sent all necessary state information to the remote host via a private channel, and the remote host is waiting for the connection to be made. The sender can break the connection immediately. The parameter specifies the address of the suggested host. It is formatted as "<ip-address> [' ' <tcp-port> [' ' commentary]]". The <ip-address> is the Internet address expressed as four decimal numbers separated by periods; optionally a DNS-style host name could be specified. Space characters are NOT allowed to appear within the name. If the TCP port number will be the default telnet service port (23), nothing more needs to be said. Otherwise a space character will be issued, followed by the port number expressed as a 1-5 digit decimal number. Finally, another space character may be issued followed by human-readable text proposing an alternate description of the channel, for instance "gopher server at Yoyodyne.com". Space characters are allowed within the commentary. An application compliant with this proposal is allowed to silently ignore the commentary. All information will be encoded using NVT ASCII. IAC SB XFER_CTRL IS <role> IAC SE The sender demands to play the specified role in all subsequent Telnet negotiations of all kinds. IAC SB XFER_CTRL SEND IAC SE The sender requests that the receiver specify which role it wishes to play in all subsequent negotiations. IAC SB XFER_CTRL INFO <role> IAC SE The sender confirms that it is to play the specified role in all subsequent negotiations. 3. Defaults WONT XFER_CTRL DONT XFER_CTRL i.e., this protocol will not be used. S. Denton Expires December 1993 [Page 3] Internet-Draft TELNET Transfer Control Option June 1993 4. Description and Implementation Notes WILL and DO are used only at the beginning of the connection to obtain and grant permission for future negotiations. Either side is free to begin negotiations. The protocol is symmetric: a person could use this option to move a Telent session from a workstation to a personal digital assistant. Only the sender of DO XFER_CTRL may send SB XFER_CTRL NAME <alternate port>; if both sides might wish to do this, they should both send DO XFER_CTRL. Note that it is common to use the word "server" to refer to the side of the connection that did the passive TCP open (TCP LISTEN state), and the word "client" to refer to the side of the connection that did the active open. In a hand-off from one client to another, the proposed recipient must have already performed a passive TCP open and be expecting the connection from the server. At this point the notions of server and client can become confused, for example, in the context of the Telnet Authentication Option. Also, it is easy to imagine that the recipient would also be willing to accept a connection from another Telnet client that wishes a "talk" connection. This is the rationale for the IS/SEND/INFO sub-protocol. Once both sides have agreed to use XFER_CTRL negotiations, they should confirm which role they wish to play for the remainder of the session. Generally, the side which performed an active open "knows" what role it should play, and should confirm this role by transmitting the IS sub-negotiation. The side which performed the passive open may have expectations regarding its role, in which case it should send the INFO sub-negotiation, or it may not care, in which case it should transmit the SEND sub-negotiation. In the latter case, once an IS sub-negotiation is received, the "passive" side should be acknowledge receipt by sending the INFO sub-negotiation. The IS/SEND/INFO sub-protocol may be used regardless of whether a side of the connection is in only the DO XFER_CTRL state, only the WILL XFER_CTRL state, or both. (The author has given much thought to a separate DO/WILL/DONT/WONT SERVE option protocol, but ultimatly rejected the idea because of the tight coupling with the XFER_CTRL negotiation and irrelevance to all other Telnet negotiations.) Because of the possible effect that the semantics of these subnegotiations can have on subsequent Telnet option negotiations, XFER_CTRL negotiations should be performed as early as possible in the session. Neither end of a connection should ever assume that any Telnet state carries over from a previous connection terminated by XFER_CTRL NAME. In particular, authentication and/or encryption should be renegotiated with as much paranoia (or as little?) as was exhibited in the original session. There does seem to be a need for an "anonymous" authentication method that can establish that multiple connections are from the same source, even though one cannot verify S. Denton Expires December 1993 [Page 4] Internet-Draft TELNET Transfer Control Option June 1993 the identity of that source. 5. Examples In the following examples, all quoted strings are NVT ASCII. 1. Server demands transfer to an alternate server. Client Server [ The client connects to the service at castor.gemini.org. ] IAC WILL XFER_CTRL IAC DO XFER_CTRL [ Time passes. Server decides to require transferring the connection to an alternate server. ] IAC SB XFER_CTRL DO "123.45.67.89 6565 SomeMud@pollux.gemini.org" IAC SE [ The server is requiring the user to reconnect to an alternate host. A comment is included to futher identify the new port. The server will break the connection at this point. The client should immediately connect to port 6565 at pollux.gemini.org. ] 2. Client connects to an alternate server supporting dynamic control transfer and reconnection. Client Server [ Client connects to server at pollux.gemini.org. ] IAC WILL XFER_CTRL IAC DO XFER_CTRL [ Client and server are connected. ] 3. Transfer of server connection from one client to another. Host 1 Host A [ Server (Host A) has connected to client (Host 1). Both sides have authenticated themselves to their mutual satisfaction. ] IAC WILL XFER_CTRL IAC DO XFER_CTRL [ Time passes. Host 1 decides to transfer the connection to an alternate host. Host 2 performs a passive TCP open on port 1234. ] IAC SB XFER_CTRL DO "44.55.66.77 1234" IAC SE [ Host 1 breaks connection. Host A performs an active TCP open to the suggested host and port. ] Host 2 Host A IAC WILL XFER_CTRL IAC DO XFER_CTRL [ Both hosts have now agreed to the XFER_CTRL protocol. ] IAC SB XFER_CTRL SEND IAC SE IAC SB XFER_CTRL IS SERVER IAC SE S. Denton Expires December 1993 [Page 5] Internet-Draft TELNET Transfer Control Option June 1993 IAC SB XFER_CTRL INFO CLIENT IAC SE [ From this point on for the purposes of this or any other Telnet option, Host A will be treated as though it had originally performed a passive TCP open (Host A is the Server) and Host 2 will be treated as though it had originally performed an active TCP open (Host 2 is the Client). ] IAC WILL AUTHENTICATION IAC SE IAC DO AUTHENTICATION IAC SE [ Both hosts agree to use the Telnet authentication option. Even though RFC 1416 specifies that only the side of the session that performed an active open may send WILL AUTHENTICATION, the successful negotiation of XFER_CTRL WILL LOGON has reversed logical direction of the connection. (Note: An ANONYMOUS authentication type has NOT been defined as of the writing of this RFC. Its use here is as an example only.) ] IAC SB AUTHENTICATION SEND ANONYMOUS CLIENT|ONE_WAY IAC SE IAC SB AUTHENTICATION NAME "john@yoyodyne.com" IAC SE IAC SB AUTHENTICATION IS ANONYMOUS CLIENT|ONE_WAY AUTH ... IAC SE IAC SB AUTHENTICATION REPLY ANONYMOUS CLIENT|ONE_WAY ACCEPT IAC SE Future directions The original concept featured a command to handle non-mandatory transfers. This idea ran aground during the initial implementation because of various uncertainties in the semantics of the command. It might be useful if the stable end of the connection could be used as the repository of connection state information during the transfer from the old host to the new. Acknowledgements Thanks to the inventor of Cyberportals, which inspired me to invent a standardized protocol to accomplish the same result. References [1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992. [2] Borman, D., "Telnet Authentication Option", RFC 1416, Cray Research, Inc., February 1993. S. Denton Expires December 1993 [Page 6] Internet-Draft TELNET Transfer Control Option June 1993 [4] Alagappan, K., "Telnet Authentication: SPX", RFC 1412, Digital Equipment Corporation, January 1985. [3] Borman, D., "Telnet Authentication: Kerberos", RFC 1411, Cray Research, Inc., January 1993. [5] Borman, D., "Telnet Environment Option", RFC 1408, Cray Research, Inc., February 1993. [6] Reynolds, J., and J. Postel, "File Transfer Protocol", RFC 959, USC/Information Sciences Institute, October 1985. Security Considerations Security issues are discussed in section 4. Author's Address Sam Denton Coal Services Corp. 301 North Memorial Drive St. Louis, MO 63102 Phone: (314) 342-7853 Fax: (314) 342-3424 Email: sunarch.central.sun.com!peabody!sam.denton This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. S. Denton Expires December 1993 [Page 7]